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A NETWORKED CLIENT-SERVER ARCHITECTURE FOR TRANSPARENTLY 
TRANSFORMING AND EXECUTING APPLICATIONS 

FIELD OF THE INVENTION 
The present invention relates to the execution of applications in a client-s 
environment. More specifically, the present invention relates to a client-server architect 
wherein an application resides on a server, and portions of the application are transformed by the 
server into a native code executable by a client, and transmitted to, cached in, and executed by 
the client. 

DESCRIPTION OF THE RELATED ART 

In the art of computing, servers and clients coupled by a network often cooperate to 
execute applications. There are many models known in the art that facilitate the 
applications in this way. For example, it has long been known to use a file server to store 
and applications. A client seeking to execute applications using this model simply accesses files 
on the server in a manner similar to the way files are accessed on a local hard drive of the client. 
Additionally, it has long been known to use interprocess communication to link distri 
applications, such as a database application executing on a server and a client appli< 
executing on a client. These models have traditionally been popular in private high-band 
networked configurations, such as an Ethernet network that couples clients and serveijs in a 
medium size business. In such environments, problems associated with computing pic 
diversity and security are manageable. 

Unfortunately, these models have proven to be impractical when used in larger, 
diverse networks, such as the Internet. One problem is bandwidth. Many clients are coupled to 
the Internet using relatively slow methods, such as dial-up modems. Even high 
connections, such as digital subscriber lines (DSL) and cable modems are typically one 
orders of magnitude slower than an Ethernet connection. 
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Another problem is security. Millions of computers are coupled to the Internet, z 
malicious attempts to break into clients and servers are common. Furthermore, software pi racy 
is often a concern. If an application is available on the Internet, it becomes difficult for a vendor 
to control the distribution of the application. Finally, the types of devices coupled to the Internet 
are very diverse. Not only are there many types of computing platforms coupled to the Inte rnet, 
but many types of Internet-enabled net appliances are becoming popular. As one can imagine, 
the problems associated with managing the execution of an application over the Interne t (or 
other large networks) using servers and clients are daunting. 

Three popular models have evolved to address these problems. These models wll be 
referred to herein as the server execution model, the download and instal model, and the vxtual 
machine model. In the server execution model, the application code remains resident on the 
server, and is executed on the server. One example of an application adhering to the server 
execution model is Quicken TurboTax® for the Web, which is a product of Intuit Inc. A user 
of this application accesses the TurboTax web site using a browser, such as Internet Exp .orer, 
which is a product of Microsoft Corporation, or Netscape®, which is a product of Netscape 
Communications. TurboTax for the Web is an interactive online tax preparation tool using 
software that remains on a secure web site. Unlike software products purchased in a retail store 
and installed on a computer, TurboTax for the Web works without downloading any software 
onto a computer. As a user of the application answers questions, the data is stored on a server, 
and the server performs all the operations necessary to prepare the user's tax forms. 

The server execution model has many advantages. First, it is very easy for the vendor to 
maintain the application, since the application can be updated on the server at any time. Also, 
this model provides excellent security and is resistant to software piracy, since the application 
code is never transmitted to the client. Finally, this model provides client-platform independence 
since all the client needs is a web browser capable of interacting with the server. 

Unfortunately, the server execution model suffers from several disadvantages. AH user 
data must be stored on the server, which increases the amount storage resources required by the 
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server. In addition, some users may feel uncomfortable having personal information stc 
a vendor's server. Also, depending on the application, this model may require a large a 
of bandwidth. For example, if a spreadsheet application were implemented using a 
execution model, and if a user attempted to create a graph of the spreadsheet data, the gra phic 
data must be transmitted to the client, which could be time consuming. Furthermore, a reliable 
connection must exist between the server and client at all times. Finally, and perhaps 
importantly, this model has poor scalability. As additional clients attempt to access the 
application, the server must execute the application for each client. 

Perhaps the most common model is the download and install model. In this model 
applications are stored on the server, arid are downloaded and installed on the client. 
Traditionally, the server maintains a separate version of the application for each type of ■ 
platform. For example, if a user wishes to install an application, such as Netscape, the 
accesses a web site maintained by Netscape Communications and downloads the version ^>f the 
application designed to operate with the user' s computer system into a directory, and installs the 
application. Application plug-ins also adhere to the download and install model. For example, 
if a user attempts to play an audio file encoded for use with RealPlayer®, which is a product of 
RealNetworks, Inc., using Internet Explorer, the user will be directed to a web site that 
downloads and installs the RealPlayer plug-in into Internet Explorer. 

The download and install model can also be automated to a certain extent. For exabple. 
recent versions of Windows® operating systems, which are products of Microsoft Corporition. 
include an automatic update feature that automatically checks a Microsoft website for updates 
to the operating system. If an update is found, the user is given the option to download 
install the update. 

One advantage of the download and install model is that it is highly scalable 
connection between the client and server is not required to execute the application. Or 
application is downloaded and installed, the client provides the storage and execution resc 
and no further interaction with the server is required. Accordingly, many clients can acc< 
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application without requiring additional server resources. Of course, this advantage provides 
several disadvantages. For example, the application is stored on the client a persistent form, thus 
exposing the application to software piracy and weakening the applicability of pay-per-use 
business models. 

Also, the burden of software management is pushed to the user. Updating appli 
installing patches, and releasing resources by uninstalling old unneeded applications are complf 
tasks, and it is desirable to avoid these tasks at the client. For example, many Internet 
familiar with the problems associated with clicking on a link that requires a certain plug-in, and 
discovering that the version of the plug-in currently installed on the user's computer is out of 
date. 

The download and install model also requires a large amount of storage resources on the 
client, since the client must store all downloaded applications. This can be a barrier for clients 
having limited resources, like embedded, portable, or mobile systems. 

The virtual machine model addresses some of the limitations of the download and 
model. One popular technology adhering to the virtual machine model is Java®, which 
trademark of Sun Microsystems, Inc. Consider a user that wishes to access a Java application 
from a web browser. References to the Java application may be embedded in a web page. When 
the user clicks on a link to invoke the Java application, the application is transparently and 
securely downloaded to the user's computer. The application is then processed by a Java virtual 
machine, which is built into the web browser. The virtual machine typically performs a series of 
security checks, and then executes the application by interpreting the Java code to conve rt this 
code into native instructions that are executed by the central processing unit (CPU) of the 1 iser' s 
client computer. The virtual machine serves as consistent interface on different kir.ds of 
computers and operating systems so that the same Java applet runs in browsers on JBM- 
compatible PCs, Macintoshes, UNIX® workstations, network computers, and other d< 
The performance of virtual machine code can be enhanced by using a "just-in-time" (JIT) 
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compiler. The JIT compiler compiles the virtual machine code into native code that executes on 
the user's client computer more efficiently than interpreted code. 

The virtual machine model is platform independent. Accordingly, a properly 
application can operate on any platform having an interpreter or a JIT compiler. In addition, 
burden of managing the application can be easily transferred from the user to the appli 
vendor, since the application can be downloaded (or a cached copy can be verified) wh< 
the application is accessed on the server. In addition, virtual machine model applications tend 
to be more resistant to software piracy. However, piracy is still an issue because the virtual 
machine code is transferred to the client. While the virtual machine model is more scalable^ 
the server execution model because execution occurs on the client, it is less scalable 
download and install model because the virtual machine model application is typically accessed 
on the server every time it is executed. Also note that a reliable connection between the 
and client may or may not be required based on how a virtual machine model applica 
implemented. 

The virtual machine model still has several drawbacks. For example, many applic 
are not available in a virtual machine format. Also, the acceptance of Java in some domains! such 
as embedded devices, is still an open issue. In addition, virtual machines always introduce some 
performance overhead (either interpretation of compilation), which can be unacceptable in some 
cases. Finally, the virtual machine model does not support legacy code applications, whith are 
typically coded for native execution on a specific computer platform. 

Virtual machine interpreters also use a non-significant amount of resources in the 
For example, a typical Java virtual machine can require 300 to 1000 kilobytes of persistent 
storage, which can comprise a significant portion of the memory available for storing code in an 
embedded device. Note that a typical embedded device may only have 8 to 16 megabytes of 
memory. Furthermore, JIT compilers typically require significantly larger amounts of persistent 
storage. 
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As can be seen from the discussion above, none of these models provide a completely 
acceptable solution to the problems associated with a client and server cooperating to execute 
an application. What is needed in the art is a single model that combines the software piracy, 
client storage requirement, application code maintenance, and platform-independence attributes 
of the server execution model, the scalability, legacy code support, and performance attributes 
of the download and install model, the client-server connection attributes of the download and 
install model, and the scalability, application code maintenance, platform-independence attri mites 
of the virtual machine model. 

SUMMARY OF THE INVENTION 

The present invention is a client-server architecture wherein an application resides dnthe 
server. When a client first seeks to execute the application, the server transmits native binary 
code segments to the client via a network connection. The client caches the segments in aJ code 
cache and executes the segments natively from the cache. 

The server includes an application code source and a server code segment manager The 
server may also include an application code transformation manager if the application code 
source is not in the native binary format of the client. The application code transformation 
manager compiles or transforms the application source into the native binary format required by 
the client. The server can be any type of server known in the art, such as a file server or a web 
server. 

The client can be any type of client known in the art, such as a computer workstation, an 
embedded device, a net appliance, a personal digital assistant (PDA), a cellular telephone, or a 
peripheral device. The client includes a client code segment manager, a code cache linker and 
manager, a code cache, and a central processing unit (CPU). The network can represent any 
type of network known in the art, such as a private Ethernet network or the Internet. 

The server code segment manager is responsible for providing binary code segments 
derived from the application code source to the client via the network. Within the client, when 



HP PDNO 1C 
Patent A 

an application is launched, the client code segment manager requests the code segment 
server code manager of the server. The client receives the code segment, and passes the code 
segment to the code cache linker and manager. The code cache linker and manager links the 
code segment with any other segments stored in the code cache, and emits the segment into the 
code cache. After the segment is emitted into the code cache, control passes to the entry point 
of the code segment in the code cache, and the client CPU begins executing the code segment. 

The code segments in the code cache are executed natively by the client's CPU 
branch is taken to a code segment not in the code cache. At this point, control passes t 
the client code segment manager, which requests the code segment containing the branch target 
address from the server. The server then transmits the needed code segment to the client, the 
code cache linker and manager links the newly received code segment into the code cache, and 
the client' s CPU continues execution with the newly received code segment in the code segment. 
This process continues until the application has finished execution. 

The present invention combines the best attributes of prior art client-server exec 
models in a single execution model. Specifically, the present invention is highly scalable since 
execution occurs on the client. In addition, since execution occurs on the client using native 
binary code segments stored in a code cache, the present inventionis potentially much faste: : than 
prior art virtual machine (VM) interpreters. However, since the application resides on the 
the user is relived of the burden of application management. 

The present invention can operate with any type of client CPU. Furthermore, appli< 
can exist on the server in a variety of code source formats, such as a native binary foi 
source code text format of a programming language, or a VM code format, thereby allowing the 
present invention to support legacy applications as well as current and future applications. 
Accordingly, the present invention is well positioned to provide a valuable client-server 
execution model capable of working with an ever increasing array of CPU instruction sets and 
application code formats. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a simplified block diagram that illustrates a client and a server coupled by a 
network, in accordance with the present invention. 

Figures 2A, 2C, and 2B, taken together, are a flow diagram that illustrates how 
application is executed in accordance with the present invention. 

Figure 3 is a block diagram of the server of Figure 1 and illustrates how the present 
invention can manage a variety of application code source formats to facilitate execution o 
variety of client CPUs. 

Figure 4 illustrates an application in the native binary format of the client of Figure 1 a 
the application resides on the server of Figure 1. 

Figure 5 illustrates code segments stored in a code cache of the client of Figure 1 aft^r the 
application of Figure 4 has finished executing on the client, with the assumption that none of the 
code segments retrieved from the server have been purged from the code cache. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
The present invention is a client-server architecture wherein an application resides on the 
server. When a client first seeks to execute the application, the server transmits native binary 
code segments to the client, which caches the segments in a code cache and executes the 
segments natively from the cache. The application source can be provided on the si 
variety of formats, such as a source code text format of a programming language, a native binary 
code format, or a virtual machine format. If the application source on the server is not n the 
native binary format of the client, then the server transforms the source into the native binary 
format required by the client. After the application begins executing on the client, when the 
application attempts to branch to a code segment that has not been cached, the client requests 
the code segment from the server, and the server transmits one or more additional code 
segments. The granularity ofthe code segments can be easily adjusted to balance server-side and 
client-side execution and network bandwidth efficiency, and client-side storage requirements. 
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The present invention encompasses several configurations for managing segments o^i the 
client. In one configuration, all segments comprising the application can be transmitted to the 
client and locked in the client's cache. This configuration would be desirable, for example, in 
a personal digital assistant (PDA) having a cellular link to the Internet. Imagine that a user of 
such a device was about to board an airplane. Before boarding the plane, the user could select 
an application (such as a game) that the user desired to use while in flight, and the application 
would be transmitted to the client via the cellular link and locked in the client's cache, 
airplane departs, the user would be able to execute the application while in flight without using 
the cellular link. After the airplane lands and the PDA reestablishes the cellular link, the 
segments in the client's code cache can be unlocked and become eligible for replacement. 

In other configurations, only a subset of the segments comprising the applicatio a a 
transmitted to the client. For example, imagine an automotive embedded device having a c 
link to the Internet. Such a device may provide access to a variety of applications, such a 
line maps and directions, maintenance and status reporting to the manufacturer, email, or games 
and other types of entertainment for the passengers. One of the characteristics of a eel 
to a client in an automobile is that as the automobile is traveling, the link may be lost for periods 
of time as the automobile travels through tunnels, around mountains or other obstructions, < 
out of range of a cellular transmitter. Accordingly, it may be desirable to only lock portici 
the application in the client's code cache. For example, assume that the user is executing a 
line map application that provides directions to a destination. The client can request all si 
required to direct the user to the destination, as well as all map data needed between the u 
current location and the destination. Should the automobile lose the cellular link while ti 
to the destination, the application can continue to execute until the automobile reaches t 
destination. 

Finally, for clients having a persistent and reliable connection to the server, such as a 
computer workstation coupled to the Internet via a DSL line or a cable modem, it is not 
necessary to lock any of the segments in the cache. In configurations where the complete 
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application is not present within the client, the present invention is highly resistant to sof 
piracy, and is therefore ideally suited for pay-per-use business models. While copying t 
application may not be theoretically impossible, it would be very difficult because one ati 
to capture the application would need to ensure that server transmits every segment, and tl 
the segments would have to be extracted from the client's code cache and reconstructed ii 
executable application. Even in configurations where the all segments have been cached ii 
client, it is still possible to frustrate piracy by using other techniques, such as encryption key 3 a 
expiration codes. Finally, extracting disjointed segments from the client's code cache, whicl 
typically contain segments from other application in a relatively random pool of segmei 
much more difficult than copying a contiguous prior art application from a region of menu 
a hard disk drive. 

Another advantage of the present invention is that since the application resides c 
server, the user is relived of the burden of application management. Also, since the c( 
executed by the client and not the server, the present invention is highly scalable. Emb< 
processors continue to become more powerful, and the present invention is well suited to exploit 
this trend in the art. While the server must still transmit segments to each client, caching the 
segments in the client minimizes this burden. In addition, by caching the segments in the c lient, 
the present invention is ideally suited for use with intermittent network connections, such a 
cellular link between the Internet and a mobile client. 

As will be seen below, the present invention can be adapted to support the exe 
a wide variety of code formats on a wide variety of platforms, thereby allowing the present 
invention to provide platform-independent execution. Accordingly, the present in 
combines the best attributes of the server execution model, the download and install mode^, < 
the virtual machine model, which are discussed above. 

Figure 1 is a simplified block diagram that illustrates a client-server configuration 10 in 
accordance with the present invention. Configuration 10 includes a server 12 and a clieit 14, 
which are coupled together by network 16. Server 10 can be any type of server known |n the 
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art, such as a file server or a web server, and includes application code source 18, application 
code transformation manager 20, and server code segment manager 22. Client 14 can b£ any 
type of client known in the art, such as a computer workstation, an embedded device, a net 
appliance, a personal digital assistant (PDA), a cellular telephone, or a peripheral device. Client 
14 includes application launch interface 24, client code segment manager 26, code cache linker 
and manager 28, code cache 30, and native instruction execution unit 32, which will typica ly be 
the client's central processing unit (CPU). Network 16 can represent any type of network 
known in the art, such as a private Ethernet network or the Internet. 

Within server 1 2, block 1 8 represents the application code source. As mentioned above, 
and as will be discussed in greater detail below, application code source 18 can be provided in 
a variety of formats, such as source code text format of a programming language, compiled 
binary code, or virtual machine code. 

Application code transformationmanager 20 is coupled to application code source 1 8 and 
is responsible for transforming segments of application code source 1 6 into binary code segments 
that can be executed natively by the client. If application code source 16 is already in the native 
binary format of the client, such as X86 code that is executed on an IBM-compatible PC client, 
minimal transformation is required. However, as will be seen below, manager 20 can also be 
provided with a compiler to transform source code text format of a prograrmriing language into 
native binary code, a code transformation engine to translate code from one binary forma t to a 
native binary format used by the client, or a virtual machine (VM) just-in-time (JIT) compiler to 
convert VM code into a native binary format used by the client. 

Server code segment manager 22 is coupled to application code transformationmanager 
22 and network 1 6. Manager 22 is responsible for providing binary code segments derivecl from 
application code source 18 to client 14. 

Within client 14, application launch interface 24 represents an interface that allows an 
application to be launched. Interface 24 represents methods of launching applications known in 
the art, such as clicking on an icon to start an application, launching a helper application from 
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a web browser, a batch file that launches a series of applications, or any other method of 
launching an application known in the art. In the prior art, when an application is launched, 
typically a file containing native code is loaded into memory, and execution begins at the entry 
point of the application in memory. In contrast, in the present invention, when interface 24 seeks 
to launch an application, interface 24 signals client code segment manager 26. 

Client code segment manager 26 is coupled to application launch interface 24, code cache 
linker and manager 28, code cache 30, and native instruction execution unit 32. When interface 
24 signals manager 26 to begin executing an application, manager 26 first determines whether 
the code segment containing the entry point of the application is in code cache 30. If it is, 
control passes to the code segment in code cache 30 and unit 32 begins executing the code 
segment. If the segment is not in code cache 30, client code segment manager 26 reques ts the 
code segment from server code manager 22 of server 12, receives the code segment, and passes 
the code segment to code cache linker and manager 28. As discussed above, client code segment 
manager 26 may also request all segments comprising the application, with the segments being 
locked in code cache 30 to allow the application to be executed when a network connecti on to 
server 12 is not present. 

Code cache linker and manager 28 is coupled to code cache 30. Manager 28 links the 
segment with any other segment stored in code cache 30, and emits the segment into code ;ache 
30. Manager 28 also performs various maintenance functions, such as removing old seg:nents 
from code cache 30 and optimizing the code segments and locking and unlocking segments, as 
will be described in greater detail below. After the segment is emitted into code cache 30, 
control passes to the entry point of the code segment in code cache 30, and unit 32 executss the 
code segment. 

The code segments in code cache 30 are executed by unit 32 until a branch is takeh to a 
code segment not in code cache 30. When this branch was emitted into cache 30, the target 
address of the branch was altered to pass control back to client code segment manager 26. 
Manager 26 requests the code segment containing the target address from server 12, ser|er 12 
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transmits the needed code segment to client 14, code cache linker and manager 28 links the 
newly received code segment into code cache 30, and native execution continues with the newly 
received segment in code cache 30. 

When executing code segments, at least a portion of code cache 30 must exist in memory 
that is coupled to native instruction execution unit 32 to allow unit 32 to natively execute the 
code segments. However, in some configurations it is desirable to also have code c 
include persistent forms of storage to allow code segments to be stored when client ] 
powered down or placed in a standby mode. Storing code segments in persistent s 
minim i yes the need to request retransmission of code segments from server 12 when cli 
is powered up or exits standby mode. For example, if client 14 is a computer system, it is 
desirable to configure code cache 30 to include a disk cache that stores code segments. 
Similarly, if client 14 is a personal digital assistant (PDA), it maybe desirable to configure code 
cache 30 to store code segments on a flash memory card. Of course, when the code segments 
are to be executed, the code segments must be loaded into memory from the persistent storage 
media. If client 14 has a virtual memory manager, code segments can be loaded from persistent 
storage by the operating system when a page fault is generated, as is known in the ar:. Of 
course, other methods can be used to move code segments between memory and pers [stent 
storage. On the other hand, client 14 need not have persistent storage media, since the code 
segments can be loaded from server 12 whenever the code segments are needed. 

The mechanism used by the present invention to manage code segments is similar to a 
mechanism disclosed in a paper entitled "Transparent Dynamic Optimization" by VasanthBala, 
Evelyn Duesterwald, and Sanjeev Banerjia, which was published in HP Labs Technical Report 
HPL-1999-77 in June, 1999, a paper entitled "Transparent Dynamic Optimization: The E esign 
and Implementation of Dynamo" by Vasanth Bala, Evelyn Duesterwald, and Sanjeev Banerjia, 
which was published in HP Labs Technical Report HPL- 1999-78 in June, 1999, and a paper 
entitled "Dynamo: A Transparent Dynamic Optimization System" by Vasanth Bala, Evelyn 
Duesterwald, and Sanjeev Banerjia, which was published in the Proceedings of the Association 
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for Computing Machinery Special Interest Group on Programming Language's Conference on 
Programming Language Design and Implementation, 2000, pp. 1-12. These three paper s are 
hereby incorporated by reference. 

These three papers describe a dynamic optimization scheme called Dynamo. Basically, 
Dynamo begins execution by interpreting native binary code. While interpreting the code, 
Dynamo identifies "hot" code segments and identifies certain optimization opportunities. The 
"hot" code segments are then optimized and emitted into a segment cache, where the "hot" code 
segments are natively executed. Rarely executed code segments continue to be executed by 
interpretation. Accordingly, an application is executed by Dynamo using a mixture of native 
execution and interpretation. In the present invention, the techniques used to manage the code 
segments are similar, but are tailored to support execution in a client and server configuration. 

As mentioned above, the granularity of the code segments can be easily adjusted to 
balance server-side and client-side execution and network bandwidth efficiency, and clien:-side 
storage requirements. Of course, the smallest possible code segment is a single binary 
instruction. However, many instructions do not branch, and execution continues with the next 
instruction in the sequence. Therefore, one implementing the present invention would typ ically 
never select single instruction granularity. 

For all practical purposes, the smallest code segment size that one implementing the 
present invention would choose is a basic block of instructions. A basic block is a set of 
instructions bounded by either branch instructions or entry points. Accordingly, instructions in 
a basic block are always executed as a group starting with an entry point or an instruction after 
a first branch instruction and ending with an instruction associated with a second branch 
instruction. Basic block level granularity is still quite small. In typical binary code, on average 
there is a branch instruction every 5 or 6 instructions. Accordingly, one implementing the 
present invention may choose to use a larger code segment granularity. Alternatively, server 
code segment manager 22 of server 12 can start by using basic block granularity, and increase 
the code segment size as basic blocks that tend to be executed together are identified. The ' arger 
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code segments can then be optimized using the techniques from the Dynamo optimization 
scheme discussed above. Also, the code segment size can be adjusted on a per-client basis to 
balance server-side and client-side execution overhead and network bandwidth efficiency, and 
the storage resources of the individual client. 

Figures 2A, 2C, and 2B, taken together, are a flow diagram 34 that illustrates how an 
application is executed in accordance with the present invention. In diagram 34, the solid-line 
blocks depict the steps required to execute the application. The dotted-line boxes correspond 
to the similarly labeled boxes in Figure 1 and illustrate where the steps are performed. 

Beginning with Figure 2A, block 36 represents the start of application execution in client 
14. Control then passes to block 3 8, which determines whether the code segment containin g the 
entry point of the application exists in code cache 30, and if it exists, whether the code segment 
is current. The determination of whether the code segment is current can occur in a number of 
ways. The whole application or individual code segments can be tagged with an expiration 
value. If the application or individual code segments have expired, than new code segmems can 
be requested from server 12. Alternatively, block 38 can communicate with server 12 to 
determine whether the application or individual code segments are current. 

Block 38 represents an important feature of the present invention in that block 38 
provides the present invention with the scalability and performance attributes of the dowiload 
and install model, and the application code maintenance attributes of the virtual machine model 
and the server execution model. Specifically, if the application is current, has been executed 
previously, and code cache 30 is large enough, the first code segment will be in code cache 30. 
Accordingly, the application will begin to execute natively as if it had been downloaded and 
installed. On the other hand, if the code segment is not present in cache 30 or is not current, the 
latest version of the code segment will be retrieved from server 12, thereby pushing the b jrden 
of application management to server 12, as in the virtual machine and server execution models. 

If the first code segment is in cache 30 and is current, the "HIT" branch is taken to block 
40. Block 40 in turn jumps to the entry point of the starting code segment in cach e 30. 
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Thereafter, execution unit 32 of client 14 executes the application from code cache 30 i 
branch instructions executed that has a target that is not in code cache 30. As will be disc 
below, the target of this branch will have been adjusted to jump out of code cache 3 0 and revest 
the needed code segment at block 44. 

Now assume that the first code segment is in code cache 30, but is not current. In this 
situation, the lower "MISS" branch is taken to block 42. Block 42 is coupled to code cache 30 
and removes the old code segment from cache 30. Note that the function performed by block 
42 can also be performed by code cache maintenance block 56 of Figure 2C, as will be < 
below. After the old code segment has been removed from code cache 30, control passes 
block 44. Returning to block 38, if the first code segment is not present in cache 30, the 
"MISS" branch is taken directly to block 44. 

Block 44 requests the needed code segment from server 12 via network 16. The 
discussion immediately above illustrated how an application is launched. Accordingly, the term 
"first code segment" was used. However, block 44 can also be reached when a 
instruction in code cache 30 that seeks to branch to a target code segment not in cache 30 is 
executed. Accordingly, the terms "needed code segment" and "received code segment" Will be 
used below in appropriate contexts. Of course, if block 44 has been reached from block 38 or 
42, the terms "needed code segment" and "received code segment" are equivalent to the term 
"first code segment". 

Server 12 needs to know which application is being executed, as well as the native binary 
format required by client 1 4. Assuming that this information has already been provided to s erver 
12 via a prior initialization dialog, the request could be as simple as providing server 12 wi th the 
target address that client 14 is seeking to execute. Control then passes to block 46 of Figure 2B. 

In Figure 2B, block 46 receives the request from client code manager 26 of client 14 via 
network 16. Control then passes to block 48, which creates and optimizes a code segment from 
application code source 1 8 for native binary execution on client 14. As will be discussed 
greater detail below, application code source 1 8 can be ASCII source code, a native code 
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(either in the format required by client 14 or another format), or a virtual machine format. . 
as discussed above, the granularity of the code segments can be dynamically tailored to b 
server-side and client-side execution and network bandwidth efficiency, and client-side s 
requirements, and can be optimized based on predicted code segment usage or prior code 
segment usage history. Control then passes to block 50, which transmits the requested code 
segment to client code segment manager 26 of client 14 via network 1 6. Control then pai 
block 52 of Figure 2C. 

While code cache 30 is shown in both Figures 2 A and 2C to better illustrate the p 
invention, there is only a single instance of code cache 30 in flow diagram 34 of Figures 2A, 2 
and 2C. In Figure 2C, block 52 receives the code segment from server code segment n 
22 of server 12 via network 16. Next control passes to block 54. Block 54 links the n 
code segment into code cache 30, emits the code segment into code cache 30, and bran 
the received code segment in cache 30. 

To link the received code segment with the code segments already in code cache 30, 
54 must modify the targets of branch instructions. First, consider the branch targets or b 
instructions that are currently in code cache 30. Before the new code segment was received, any 
branch targets in code segments stored in code cache 30 that need to branch to the r.ewly 
received code segment had been previously adjusted to branch out of code cache 30 to b 
to request the needed code segment. Now that this code segment will be in code cache 30, the 
targets of these branch instructions must be adjusted to branch to the appropriate 1 
within the received code segment. 

Next, consider the branch targets of branch instructions in the newly received c 
segment. Any branch instructions having branch targets in the newly received code segment that 
branch to code segments currently in code cache 30 need to be adjusted to branch to the 
appropriate code segments in cache 30. Furthermore, any branch instructions having branch 
targets in the newly received code segment that branch to code segments not in code cache 30 
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need to be adjusted to branch out of code cache 30 to block 44 to request the code s 
containing the desired target address. 

After the branch targets have been adjusted, the received code segment is emitted i 
code cache 30, control passes to the received code segment, and native instruction execution unit 
32 executes the received code segment (and possibly other code segments) until i 
instruction is reached that needs to branch a code segment not currently in code cache 30. 
discussed above, this branch instruction will have been adjusted to pass control to block A 
retrieve the needed segment from server 12. To adjust branch instruction targets as des( 
above, code cache linker and manager 28 maintains a table of branch instructions and b 
targets. 

Note that when block 54 attempts to link and emit the newly received code segment ii 
code cache 30, cache 30 maybe full. In this situation, block 54 signals code cache maintenance 
block 56 to remove unneeded or old code segments. Typically, block 56 will use a replacement 
algorithm to determine which code segments are eligible for replacement. Block 56 rnaji also 
operate independently of block 54 to maintain a certain amount of free space in code cache 30 
by continuously removing old or unneeded code segments. 

One replacement algorithm known in the art is the least recently used (LRU) algoi 
Using the LRU algorithm, the segments which have not been used for the longest period of time 
are replaced first. However, it is also possible to have block 54 use a more sophisticated 
approached to manage the segments in code cache 30. In one approach, block 50 periodically 
profiles the execution to better understand the relative importance and shape of the applies 
"hot paths" using the same techniques as Dynamo, which was discussed above. By profiling the 
execution of code in code cache 30, it is possible to make predictions of the future e 
paths ofthe application based on previous history, and consequently make better decisions a 
which segments to replace. Of course, this approach incurs a certain amount of overhead. 

Another approach (which is the opposite in philosophy) attempts to minimize the oache 
management overhead by periodically flushing the whole cache whenever the numoer of 
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replacements reaches a certain threshold. This method is very simple, and effectively captures 
program "epochs" (completely different application phases that each use a different set of code 
segments). 

As mentioned above, it may be desirable to have client 14 lock all or a portion of the 
native binary code segments comprising an application in code cache 30 to ensure that the 
application can continue executing in the event that the network connection to server 12 is 
temporarily unavailable. In one of the examples discussed above, a user can request that all 
segments comprising an application be loaded into code cache 30 and locked. In this example, 
application launch interface 24 of Figure 1 can present the user with this option, block 44 of 
Figure 2A can request all segments from server code segment manager 22 of server 12, and 
block 28 of Figure 2C can set a "lock bit" associated with each segment as the segments are 
emitted into code cache 30. In another example discussed above, an application may request that 
certain segments of the application be locked in code cache 30, such as all the application 
segments and data needed to guide an automobile driver from a present location to a destination. 
In this example, block 44 of Figure 2A can be provided with an application program interface 
(API) to allow the application to request that certain segments be loaded into code cache 30 and 
locked. 

If the present invention is provided with the ability to lock segments in code cache 30, 
then code cache maintenance block 56 of Figure 2C will manage the locked segments. In one 
configuration, block 56 can manage the locked segments as part of the cache replacement 
scheme. For example, block 56 could retain all locked segments until cache 30 becomes fall by 
replacing unlocked segments first, and then replacing locked segments using a replacement 
algorithm, as discussed above. Alternatively, block 56 could generate a warning to the user 
indicate that no new applications can be launched until cached and locked applications are 
explicitly unlocked. Note that block 56 can also be provided with an API to allow an application 
to unlock segments that are no longer needed. In the example above, when the driver reaches 
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the destination the on-line map application can signal block 56 to unlock all segments that v 
used to guide the driver to the destination. 

In the discussion above, note that native binary code segments are stored in code dache 
30. However, segments containing data can also be stored in code cache 30, as in the or -line 
map application example discussed above. Those skilled in the art will appreciate that the 
techniques disclosed herein can easily be extended to include data segments as well. To 
appreciate how this can be done, consider three different types of data "objects" that are 
commonly used by an executing application. 

The first type of data object is data that is statically compiled along with the application. 
To handle this type of data object, client code segment manager 26 can be provided with a data 
cache manager that manages data segments in cache 30. Basically, when an application is 
launched, the CPU is configured to generate a page fault when an attempt is made by the 
application to access regions of memory in which the application expects data to be stored. 
These page faults are serviced by the data cache manager, which loads the data segments f 



from 

the server, stores the data segments in cache 30, and maps the application data accesses to 

those 
data 



regions in cache 30. Note that these functions can be provided using functions similar to 
provided by a virtual memory manager. When cache 30 has reached a certain threshold fo: 
segments, dirty segments must either be moved to some other type of storage, or be written back 
to the server before new data segments can be loaded into cache 30. 

The second type of data object is data that is dynamically allocated by the application. 
In this case, low-level system calls adapted for use with the present invention can be link ed to 
the application by server 12. For example, the Unix function sbrk is called by an application to 
change the amount of space allocated to a data segment associated with the calling application. 
Accordingly, a version of the function sbrk customized to allocate memory in client 14 is linked 
to the application at server 12 before code segments are transmitted to client 14. When this 
function call is executed by client 14, the client 14 will allocate memory for the data segment. 



-20- 



HP PDNO 1( 

Patent Application 

Note that the memory maybe allocated within or outside of cache 30, and a caching policy may 
be used as discussed above. 

The third type of data object relates to data stored in files. One way to handle 
objects is to have each application mount its own file system on a "networked block dev 
with the "networked block device" under control of the data cache manager. Accordingly, an 
access to a file generates a fault that is serviced by the data cache manager, which in turn .oads 
the file data from server 12 into memory of client 14. 

Note that the application (or lower level functions linked to the application) 
provide support for the first and second data object types, but application support for the 
object type could be provided other mechanisms, such as direct access to networked 
sharing at the NFS level, or other networked file access mechanisms. 

Figure 3 is a block diagram of server 12 and illustrates how the present invention can 
manage a variety of application code source formats to facilitate execution on a variety of client 
CPUs. In Figure 3, two different CPU types are shown, Type I and Type II. For example, the 
Type I CPU can be an X86 CPU commonly found in Microsoft Windows® compatible desktop 
computers, and the Type II CPU can be a 32-bit Hitachi SH3 Processor, which is used ip the 
Hewlett-Packard Jornada 500 Series of Pocket PCs, or a StrongARM® RISC processor, which 
is a processor core licensed by ARM® Limited and is used in many embedded devices. 

The code sources for the applications are stored in application code source 18. 
Application A is shown in block 5 8 and represents an application code source in a native t inary 
format for CPU Type I, such as a legacy X86 application. Application B is shown in bio ;k 60 
and represents an application code source in the source code text format of a programming 
language, such as C++. Finally, Application C is shown in block 62 and represents an appli 
code source in a virtual machine format, such as a Java® application. 

Application code transformation manager 20 is responsible for transforming each 
Applications A, B, and C into native binary formats for CPU Types I and II, and server code 
segment manager 22 stores each application in the native binary format for each CPU type. First, 
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consider a client having a Type I CPU and seeking to execute Application A. Since Application 
A is already in the format required by the client, the code source flows from block 58 through 
application code transformation manager 20 without transformation to block 64 of server code 
segment manager 22. Block 64 represents Application A in the native binary format of CPU 
Type! 

Next consider a client having a Type II CPU and seeking to execute Application A. 
Application A is not in the native binary format of the client, so the code source flows to block 
66 of manager 20, which is a CPU Type I to CPU Type II transformation engine. After the 
application has been transformed into the native binary format of CPU Type II, the code :lows 
to block 68 of manager 22, which represents Application A in the native binary format of CPU 
Type II. Transformation engines that translate code from one binary format to another are 
known in the art. One such transformation engine known in the art is the code morphing 
software layer present in the Crusoe™ series of processors, which are a product of Transmeta 
Corporation. Basically, the code morphing software layer of a Crusoe processor is a dynamic 
translation system that compiles instructions from the X86 instruction set into instructions for 
a very long instruction word (VLIW) instruction set that is the native instruction set of the inner 
core of the Crusoe processor. The code morphing software layer of a Crusoe processor is 
described in greater detail in a paper entitled "The Technology Behind Crusoe™ Processors: 
Low-Power X86-Compatible Processors Implemented with Code Morphing™ Software" by 
Alexander Klaiber, which was published in January of 2000. This paper is hereby incorporated 
by reference. 

Next, consider a client that seeks to execute Application B. This application code s Durce 
is provided in a prograrnming language source code text format, such as C++ source code or 
Visual Basic® source code. Visual Basic® is a trademark of Microsoft Corporation. If the 
client has a Type I CPU, the source code flows from block 60 to block 70 of manager 20, which 
represents a compiler that compiles and links the application into native binary code for CPU 
Type I. The compiled code then flows to block 72, which represents Application B in the native 
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binary format of CPU Type I. Similarly, if the client has a Type II CPU, the source code Hows 
from block 60 to block 74 of manager 20, which represents a compiler that compiles and links 
the application into native binary code for CPU Type II. The compiled code then flows to block 
76, which represents Application B in the native binary format of CPU Type II. 

Finally, consider a client that seeks to execute Application C. This application 
source is provided in a virtual machine (VM) format, such as a Java application. If the client has 
a Type I CPU, the VM code flows from block 62 to block 78 of manager 20, which represents 
a just-in-time (JIT) compiler that compiles and links the VM application into native binary code 
for CPU Type I. The compiled code then flows to block 80, which represents Application C in 
the native binary format of CPU Type I. Similarly, if the client has a Type II CPU, the 
code flows from block 62 to block 82 of manager 20, which represents a JIT compiler that 
compiles and links the VM application into native binary code for CPU Type II. The compiled 
code then flows to block 84, which represents Application C in the native binary format of CPU 
Type II. 

Note that the steps discussed above can be performed before a client requests a code 
segment, or upon demand by the client. Block 86 represents server code segment manag er 22 
transmitting application segments from Applications A, B, and C to clients having CPU types 
and II. Block 86 represents the functions performed by blocks 46 and 50 in Figure 2B. 

Figure 4 illustrates an application 88 in the native binary format of client 1 4 as appli 
88 resides on server 12 in server code segment manager 22, and Figure 5 illustrates the segment; 
stored in code cache 30 of client 14 after application 88 has finished executing on client 14, with 
the assumption that none of the segments retrieved from server 1 2 have been deleted from cache 
30. In Figure 4, program 88 comprises segments A, B, C, D, E, F, G, H, I, and J. The lines 
connecting the segments represent possible execution paths. The solid lines represent execution 
paths actually traversed by client 14, and the dotted lines represent execution paths not traversed 
by client 14. 
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Accordingly, execution begins at block 90, which represents block 3 6 ofFigure2A. ^irst, 
segment A is retrieved from server 12 and is emitted into code cache 30. Note that segment A 
can flow to segments B or C, so these exit points are adjusted in cache 30 to pass control back 
to block 44 in Figure 2A to request the next segment. In this example, path 92 is taken, so 
segment B is retrieved from server 12. When segment B is emitted into cache 30, path 92 from 
segment A to B is adjusted to branch to segment B in the code cache. In addition, segment B 
can flow to segments C or D, so these exit points are adjusted in cache 30 to pass control back 
to block 44 to request the next segment. This process continues, with path 94 taken to retrieve 
segment C, path 96 taken to retrieve segment D, and path 98 taken to retrieve segment E;. 

Segment E can flow to segments B or F. Since segment B is already in cache 30, path 
1 00 is adjusted to flow to segment B in code cache 3 0, and path 1 02 is adjusted to pass control 
back to block 44 to retrieve segment F. Now assume that a loop is executed a number of l imes 
through segments B, C, D, and E via paths 100, 94, 96, and 98. This loop will be executed by 
client 14 from code cache 30 without having to retrieve any additional segments from server 12. 

When the loop terminates, path 102 will be taken to retrieve segment F, path 104 will be 
taken to retrieve segment I, and path 1 06 will be taken to retrieve segment J. Finally, program 
execution terminates at end block 108, Note that segments G and H are never executed, and 
therefore are never transmitted from server 12 to client 14. 

Figure 5 shows the contents of code cache 30 of client 14 after program 88 has finished 
executing, with the assumption that none of the segments were purged from cache 30. Note that 
in Figure 4, segment G can be reached from segments C and F. Since segment G was never 
loaded into cache 30, segments C and F still have exit points that have been adjusted to pass 
control to block 44 to retrieve segment G from server 12. Similarly, segment H can be reached 
from segments G and J. Segment G is not in cache 30. However, segment J still has an exit 
point that has been adjusted to pass control to block 44 to retrieve segment H from server 12. 

Also note that in code cache 30, not only are segments linked by the execution path 
actually taken, but also by possible execution paths connecting segments in cache 30 that were 



-24- 



HP PDNO 1( 

Patent Application 

not taken. Accordingly, the next time client 14 seeks to execute program 88, execution can 
occur completely from code cache 30 until either segment G or H is needed. 

Many of the advantages of the present invention, taken individually, can be found h 
of the client-server execution models of the prior art. However, what sets the present inve: 
apart from the prior art is that the present invention combines the best attributes of prior a 
client-server execution models in a single execution model. Specifically, the present ii 
is highly scalable since execution occurs on the client. In addition, since execution occurs o 
client using native binary code segments stored in a code cache, the present invention is 
potentially much faster than prior art VM interpreters. 

Since code segments can be stored and locked in the code cache of the client, e 
can continue if the network connection to the server is temporarily interrupted. As d 
above, applications transmitted to the client are highly resistant to software piracy, making the 
present invention well suited for pay-per-use business models. In addition, since the application 
resides on the server, the user is relived of the burden of application management. 

The present invention can operate with any type of client CPU. Furthermore, applic; 
can exist on the server in a variety of code source formats, such as a native binary forr 
source code text format of a programming language, or a VM code format, thereby allowing tl 
present invention to support legacy applications as well as current and future applic 
Accordingly, the present invention is well positioned to provide a valuable client-server 
execution model capable of working with an ever increasing array of CPU instruction sets and 
application code formats. 

Although the present invention has been described with reference to preferred 
embodiments, workers skilled in the art will recognize that changes may be made in form a 
detail without departing from the spirit and scope of the invention. 
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